1. Field of the Invention
The present invention relates generally to management of computer applications. More particularly, the present invention relates to a system and method for specifying virtual machines so that an application is executed in the virtual machine best suited for that application.
2. Description of the Related Art
This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the claims in this application and is not admitted to be prior art by inclusion in this section.
Java is a simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, multithreaded, dynamic, buzzword-compliant, general-purpose programming language developed by Sun Microsystems in the 1990's. Java supports programming for the Internet in the form of platform-independent Java “applets”. Java is similar to C++ without operator overloading (though it does have method overloading), without multiple inheritance, and extensive automatic coercions.
Java programs can run stand-alone on small computers. The interpreter and class support take about 40 kilobytes (Kb); adding the standard libraries and thread support (essentially a self-contained microkernel) adds an additional 175 Kb. Java extends C++'s object-oriented facilities with those of Objective C for dynamic method resolution. Java has an extensive library of routines for TCP/IP protocols like HTTP and FTP. Java applications can access objects across the Internet via URLs as easily as on the local file system.
The Java compiler and linker both enforce strong type checking in that procedures must be explicitly typed. Java supports the creation of virus-free, tamper-free systems with authentication based on public-key encryption. The Java compiler generates an architecture-neutral object file executable on any processor supporting the Java run-time system. The object code consists of byte-code instructions designed to be both easy to interpret on any machine and easily translated into native machine code at load time.
Java applications may come in many forms depending on the application's configuration and profile. The configuration is the specification that defines the minimal feature set of a complete Java runtime environment A configuration may be thought of as a vertical set of application programming interfaces (APIs) that provide the base functionality for a particular range of devices that share similar characteristics, such as memory footprint and network connectivity. A configuration also defines a Java virtual machine to be used on different types of devices and says what the virtual machine can do and what the virtual machine needs. The configuration used in a device depends on the amount of memory on the device and in general, a configuration requiring a system with more memory is more comprehensive in its features. For instance, connected limited device configuration (CLDC) is used in devices which have memory of about 160 Kb and upwards. Such devices include cell phones, 2-way pagers, and cheap home appliances. Connected device configuration (CDC) is used in devices which have about 2 Megabytes (Mb) of memory and upwards. Such devices include expensive home appliances and car navigation systems. Regardless of the configuration, all applications on a device are generally executed in the same virtual machine.
A profile is a specification that details the Java technology application programming interfaces (APIs), built on top of and utilizing the underlying configuration, necessary to provide a complete runtime environment for a specific kind of device. Profiles specify both APIs and the configuration if offered. A profile must be complete in the sense that an application written to the specification can execute in the specified Java technology environment without the addition of other Java classes. Profiles can be thought of as selecting classes from APIs to form a complete environment.
The Mobile Information Device Profile (MIDP) for example, provides a standard platform for small, resource-constrained, wireless mobile information devices. One can think of the CLDC as a horizontal set of classes, and the MIDP, which is built on top of CLDC, as a vertical set of classes. This means that MIDP has access to all the classes provided by the CLDC. Another type of profile is the Java personal profile. Personal profile, which is built on top of CDC, is a set of Java APIs that supports resource-constrained devices with a graphical user interface (GUI) toolkit based on the abstract window toolkit (AWT). Combined with the CDC, Java 2 Micro Edition (J2ME) personal profile provides a complete J2ME application environment for consumer products and embedded devices. Other CDC based profiles include foundation profile and personal basis profile.
One type of application is the MIDlet. A MIDlet is CLDC based and is the basic unit of execution in MIDP. MIDlets may be bundled into MIDlet suites, which in turn are encapsulated within Java archive (JAR) files. MIDlet suites, which may contain numerous MIDlets, include the appropriate components for the target user, device, network, and locale. FIG. 1 illustrates the components of a conventional JAR file. A MIDlet suite's JAR file 100 will generally contain the class files implementing the MIDlet(s) 102, any resource files used by the MIDlet(s) 104, and a file manifest 106 describing the JAR file contents.
The JAR file manifest 106 provides a means to encode information about the contents of the JAR file. In particular, the JAR file manifest specification provides for name-value pairs, or tags, which a configuration uses to encode MIDlet attributes. Several attributes commonly found in a JAR file manifest 106 are shown in FIG. 1. MIDlet Name 108 is the name of the MIDlet suite and identifies the MIDlet(s) to the user. MIDlet Version 110 is the version number of the MIDlet suite and can be used by the system for installation, upgrades, and communication with the user. MIDlet Vendor 112 is the name of the MIDlet suite provider. MIDlet Icon 114 is the name of a portable network graphics (PNG) file to be used as the icon to identify the MIDlet suite to the user. MIDlet Description 116 is a short description of the MIDlet suite. MIDlet Info URL 118 is a uniform resource locator (URL) for information further describing the MIDlet suite. MIDlet <n>120 is the name, icon, and class of the nth MIDlet in the JAR file. MIDlet Jar URL 122 is the URL from which the JAR file was loaded. MIDlet Jar Size 124 is the size of the JAR file in bytes. MIDlet Data Size 126 is the minimum number of bytes of persistent data required by the MIDlet. Microedition Profile 128 is the Java 2 Micro Edition (J2ME) profile required. Lastly, the Microedition Configuration 130 is the J2ME configuration required.
Java applications are executed in a virtual machine, which is a specification for software that interprets programs that have been compiled into byte-codes. Devices are generally equipped with only one virtual machine to execute all of the applications used by the device. This is due to memory constraints in devices and the fact that one of the Java design goals is to have one virtual machine for all applications. However, memory constraints are no longer a major limitation, as even small devices can now contain large memories. Also, different configurations work better with different virtual machines and not all virtual machines can run both CDC and CLDC based applications. However, traditional application installation and execution has no way to account for this, so performance may be less than optimal.
During installation, an application is installed and will subsequently be launched and executed in the virtual machine on the device. This happens the same for all applications, regardless of the configuration or profile. This prevents optimal performance because, as mentioned above, different configurations run better with different virtual machines and a given virtual machine may not support all configurations and profiles. Also, even if a device does have more than one virtual machine to accommodate various applications, there is no way to specify which virtual machine should execute a particular application. Thus, there is a need for more than one functional virtual machine on devices which contain both connected device and connected limited device configurations. Further, there is a need to specify which virtual machine on a device should execute a particular application. Further yet, there is a need to ensure that the specified virtual machine executes the application each time the application is launched.